package P134_UseLookListenQuestionFeelPulse;

/**
 * Desc:&emsp;&ensp;使用望闻问切诊断行性能
 *
 * @author 李渊&emsp;liyuan7@yusys.com.cn
 * @version 1.0
 * @since V4.3&emsp;2022/5/20
 */
public class UseLookListenQuestionFeelPulse {
    /*
    * 望：
    *   1. 难以重现的偶发性问题
    *       闻问切
    *   2. 可重现的性能问题
    *       客户打电话给我们， 反映系统性能缓慢， 不需要我们赶到现场， 自己观察一下生产机就
        可以发现部分交易缓慢， CPU 过高， 可用内存较低等问题， 在这种情况下我们至少要测试三
        个有性能问题的交易（ 或者三个与业务相关而技术无关的功能， 或者与技术有关而业务无关
    */
    /*
    * 闻：
    *   “ 闻” 是关注项目被动产生的信息， 其中包括： 项目组的技术能力（ 主要取决于技术经理
    *   的技术能力） 、文化氛围、群体的习惯和习性， 以及他们专注和擅长的领域等
    *
    *   1.如果项目组的技术能力很强， 有资深的数据库专家， 有顶尖的架构师， 也有首席程序
    *   员， 那性能问题产生的根源就应该定位在无意识的代码缺陷上。
    *   2.如果项目组的文化氛围很槽糕， 组员不交流， 没有固定的代码规范， 缺乏整体的架构
    *   等， 那性能问题的根源就可能存在于某个配置上， 或者相互的接口调用上。
    *   3.如果项目组已经习惯了某一个框架， 而且也习惯了框架的种种约束， 那性能的根源就可
    *   能是有人越过了框架的协约。
    *
    *   需要注意的是， “ 闻” 并不是主动地去了解， 而是由技术（ 人或应用） 自行挥发出的
    *   “ 味道” ， 需要我们要敏锐地抓住， 这可能会对性能分析有非常大的帮助。
    */

    /**
     * 问：
     * “ 问” 就是与技术人员（ 缔造者） 和业务人员（ 使用者） 一起探讨该问题， 了解性能问题，如这样问
     * 性能是不是一直这样慢， 从何时起慢到不能忍受？
     * 哪一个操作或哪一类操作最慢， 大概的等待时间是多长？
     * 用户的操作习惯是什么， 是喜欢快捷键还是喜欢用鼠标点击？
     * 在什么时间段最慢， 业务高峰期是否有滞顿现象， 业务低谷是否也缓慢？
     * 其他访问渠道， 如移动设备是否也有效率问题？
     * 业务品种和数量有没有激增， 操作人员是否大规模增加？
     * 是否在业务上发生过重大事项或重要变更， 当时的性能如何？
     * 用户的操作习惯有没有改变， 或者用户是否自定义了某些功能？
     * 而对于技术人员， 我们就要从技术角度来询问性能问题了， 而且由于技术人员对系统了
     * 如指掌， 可能会“ 无意识” 地回避问题， 我们应该有技巧地处理这类问题， 例如可以这样来
     * 向问技术人员：
     * 系统日志是否记录了缓慢信息， 是否可以回放缓慢交易？
     * 缓慢时系统的CPU 、内存、I/O 如何？
     * 高峰期和低谷时业务并发数量、并发交易种类、连接池的数量、数据的连接数景如何？
     * 最早接到用户投诉是什么时候， 是如何处理的， 优化后如何？
     * 数据量的增长幅度如何， 是否有历史数据处理策略？
     */

    /**
     *  切：
     *  ”切” 是“ 四诊” 的最后一个环节， 也是最重要的环节， 这个环节结束我们就要给出定
     * 论： 问题出在什么地方， 该如何处理等。Java 的性能诊断也是类似的， “ 切” 就要我们接触
     * 真实的系统数据， 需要去看设计， 看代码， 看日志， 看系统坏境， 然后是思考分析， 最后给
     * 出结论。在这一环节中， 需要注意两点： 一是所有的非一手资料（ 如报告、非系统信息） 都
     * 不是100 ％ 可信的， 二是测试环境毕竟是测试环境， 它只是证明假设的辅助工具， 并不能证
     * 明方法或策略的正确性。
     */
}
